要做Scrum，我们所需要的只是16个必需品，即3个角色，3个文物，5个价值观和5个事件。这些16个要素通过Scrum指南中描述的某些规则和指南绑定在一起。这些规则和指南可帮助Scrum团队尽可能充分利用Scrum框架来创建最大的业务影响。
Scrum是3355的组合.scrum框架的核心概念可以简单地记为3.3.5.5，如下所示：
3355的目标落后于三个Scrum支柱
“完成”（DoD）的定义是通过Scrum团队的5个事件来实现3个支柱来实现的。
3355 Scrum框架
当我提到规则时，我的意思是那些无法修补以适应特定背景的方面。例如：没有3个角色，你不能做Scrum - 产品负责人，开发团队和Scrum Master。
当我提到指南时，我指的是那些可能被改变以适应特定背景的方面; 然而，影响只能在实施后进行验证。然后我们相应地检查(insepction) 和调整(adaptation)。
例如，Product Backlog Refinement消耗的不超过团队容量的10％ (<10% of the sprint duration)。是容量-小时数;故事点数; ＃天-好吧，没有规则。Scrum团队自我组织并选择最适合他们背景的东西;遵循我们消耗的指导方针，无论如何不超过团队容量的10％。
在这篇文章中，我将探讨一些这样的指导方针，这些指南将11个要素绑定在一起，并赋予Scrum团队灵活性以适应这些方面的背景。
1。开发团队规模：开发团队的规模 建议为3-9名成员。根据具体情况，可能会有更多人或更少。它的影响因团队环境而异。
来自Scrum指南：
不到三个开发团队成员减少了交互，导致生产率降低。较小的开发团队可能会在Sprint期间遇到技能限制，导致开发团队无法提供可能可释放的增量。拥有超过九名成员需要太多协调。大型开发团队为实证过程提供了太多的复杂性。
2。开发团队的标题/角色： Scrum不承认开发团队中的任何标题/角色。在开发团队中，每个人都是开发团队成员。虽然在组织内，团队成员可能拥有头衔/角色。根据我的经验，我与Scrum有关;我没有遇到任何只有一个职位/角色的团队。
3。每日Scrum的三种问题格式： 我使用过的大多数团队都使用Daily Scrum的3个问题的格式：
令人惊讶的是，这3个问题只是开始使用Scrum的团队的模板。只要他们专注于Sprint目标的进展，开发团队就可以以他们认为合适的任何方式构建Daily Scrum。
4。事件的时间框**：事件** 的时间框表示事件为1个月冲刺所允许的最长时间。准则是：对于较短的短跑持续时间，它通常较短。
这是否意味着，对于为期两周的Sprint，Sprint Planning的时间限制为4小时，Sprint Review为2小时，Sprint回顾为1小时和半小时？编号
为尽可能满足他们的目的所需要的事件可以短/长;但不能超过最大分配时间。例如：Sprint规划活动为期2周Sprint可能会在2小时内结束，如果达到目的，或者可能会持续到8小时（如果没有）。
5。进展趋势： Scrum指南建议使用烧毁图表，累积流量等实践来监控进度趋势。但是，团队完全可以自由选择他们认为合适的任何练习来达到目的。根据我的经验，我见过团队创建视觉路线图，基于里程碑的进度，旅程线，发布燃烧图等。虽然，我们还需要记住在复杂的环境中;只有经验数据才能帮助我们做出正确的决定。
6。估算： 该的Scrum指南介绍了积压的产品项目需要估计。他们应该如何估计完全取决于Scrum团队。故事点，理想日，T恤尺码，狗尺码是一些方法。
Scrum团队可以做“没有估计”吗？当然，只要Scrum团队能够起草一份支持经验主义的计划; 创建透明度并帮助团队在Sprint结束时创建可能可释放的“完成”增量; 没关系。Scrum团队自行组织选择适合其背景的内容。
7。工作分解： 在“选择的工作将如何完成？”部分。对于Sprint计划，Scrum指南提到 -
开发团队在Sprint的头几天计划的工作在本次会议结束时分解，通常分为一天或更短时间。
这通常有助于发展团队这样做，但这并非强制要求。根据我的经验，我已经看到几个团队没有将工作项目细分到如此精细的水平。他们非常清楚如何将功能转换为“完成”增量。
8。Sprint评审： 这是一项重要的Inspect＆Adapt活动，Scrum团队与主要利益相关方就Sprint期间取得的成果进行合作，以及在下一个Sprint中可以做些什么来优化产品的价值。
Scrum指南还描述了Sprint Review的一部分：
- 与会者包括Scrum团队和产品负责人邀请的主要利益相关者
- 产品负责人解释了产品待办事项项目已“完成”且未完成的内容
- 开发团队讨论Sprint期间的情况，遇到的问题以及这些问题是如何解决的
- 开发团队演示了它“完成”的工作并回答了有关增量的问题
- 产品负责人会按原样讨论产品Backlog。他或她根据迄今为止的进展预测可能的目标和交付日期（如果需要）
- 整个小组就下一步做什么进行合作，以便Sprint Review为后续的Sprint Planning提供有价值的信息
- 回顾产品的市场或潜在用途如何改变下一步最有价值的事情
- 审查下一个预期的产品功能或功能版本的时间表，预算，潜在功能和市场
对于每年获得资助的Scrum团队来说，每两周进行一次Sprint评估的预算是否合理？也许不吧。
并非所有上述元素都适用于所有Scrum团队。它们作为指导提供，以便Scrum团队可以选择在Sprint评审期间讨论和触及产品交付的各个方面，因为他们认为适合他们的背景。
9。发布到生产： 每个Sprint的目的是创建可能可释放的“完成”增量。这意味着增量需要处于可用状态并符合Scrum团队的DoD。
但是，将增量发布到生产中的选择由产品负责人决定。基于团队的背景和他们创造的增量; Scrum团队可能决定每个sprint执行多个版本，每个sprint一个版本或多个sprint的累积发布;无论如何优化产品的价值。
10。完成的定义：完成的 定义有助于提高透明度并创建对完成工作意味着什么的共同理解。根据Scrum指南，Scrum团队有望扩展其国防部并使其更高质量的更严格。
同样，这不是一个规则。取决于团队的背景; Scrum团队可能会在每次回顾中重新审视它的国防部，或者可能继续使用相同的国防部，除非它学会了新的东西以提高产品的质量。
这些只是在Scrum指南中传播的一些指导原则。我想提出这个区别，因为我经常发现Scrum团队对Scrum规则和指南感到困惑。很少有人很常见- 将Sprint Planning的时间框修改为4小时进行为期2周的冲刺，或者开发团队花费太多时间和精力将Product Backlog Items (PBI) 分解为“任务” - 其他人则不那么常见。我相信这篇文章将帮助团队识别Scrum的一些方面，他们可以修改这些方面以适应他们的背景，以及他们能够区分那些无法改变的方面。
warren2lynch
iThome鐵人賽
看影片追技術